In a typical legacy data processing system, firmware provides the machine instructions that control the system when the system is being powered up or has been reset, but before an operating system (OS) is booted. That is, the firmware controls the pre-OS or pre-boot operations. Firmware may also control certain operations after the OS has been loaded, such as operations for handling certain hardware events and/or system interrupts. The firmware may handle pre-boot and post-boot operations through a set of routines referred to collectively as a basic input/output system (BIOS). The BIOS thus provides the interface between the hardware components of the system and software components such as the OS. Accordingly, firmware for a legacy system is generally written specifically for the hardware platform within which the firmware will operate.
For purposes of this disclosure, the term “firmware” is used to refer to software that may execute in a processing system before the processing system has booted to an OS, software that may provide runtime services that allow the OS or other components to interact with the processing system hardware, and similar types of software components. Traditionally, firmware has typically been stored in non-volatile memory. In more recent years, however, processing systems have been developed that store firmware in or obtain firmware from other types of storage devices or from remote repositories.
In addition, not long ago, the Extensible Firmware Interface (EFI) model was announced. The EFI model provides a model for an interface between platform firmware and higher-level software such as operating systems. Version 1.10 of the EFI Specification, dated Dec. 1, 2002, may be obtained from www.intel.com/technology/efi/main_specification.htm. The EFI specification defines a set of standard interfaces and structures to be provided by low-level platform firmware. Those interfaces and structures may be used for tasks such as loading additional firmware, running pre-boot applications, booting the OS, and providing runtime services after an OS has been booted.
The EFI model requires software modules such as firmware drivers, pre-OS applications, and modules for providing runtime services to be formatted according to the portable executable (PE) format. The PE format is the file format that Microsoft Corporation adopted as the standard format to be used for executable files to run under operating systems such as Microsoft® Windows® NT, Microsoft® Windows® XP, Microsoft® Windows® 2000, and Microsoft Windows CE®. The term “portable executable” reflects an intention to provide a common format for executable files for multiple operating systems. PE files may run on multiple different hardware platforms, including 32-bit architectures and 64-bit architectures. Microsoft® linkers can be used to generate executable files in the PE format from object files in the Common Object File Format (COFF). COFF is the file format used for object files generated by Microsoft® compilers. The PE format and the COFF format are both described in revision 6.0 of the “Microsoft Portable Executable and Common Object File Format Specification,” dated February 1999 (the “PE/COFF Specification”), available at www.microsoft.com/whdc/system/plafform/firmware/PECOFF.mspx. One advantage of using PE images pertains to flexibility, as a PE image is easy to relocate from one memory base to another, as long as the image contains relocation data.
Platform frameworks based on the EFI model, such as the Intel® Platform Innovation Framework for EFI, are expected to supplant frameworks based on the conventional BIOS model within the next few years as the frameworks of choice for designing, building, and operating data processing systems. An EFI-based platform framework may include low-level firmware or software that provides boot and runtime service calls that are available to other software components, such as the operating system and its loader. In particular, EFI-based platform frameworks are expected to use a modular architecture, in which the PE image format is used by the firmware or software modules that provide service calls such as those referenced above.
Conventional PE image files are organized into sections or segments. For purposes of this disclosure, the modules for providing runtime services within an EFI-based framework may be referred to in general as runtime drivers. Generally, the PE image for a runtime driver will have four segments, known as .data, .rdata, .text, and .reloc. By default, all of the code will be put into the text segment, and all writeable data will be put in the .data segment.
Runtime drivers are required to reside in a special memory range to provide EFI runtime services for the OS. Typically, this memory range is referred to as the EFI runtime memory. The OS preserves the EFI runtime memory for the exclusive use of the runtime drivers.